AutoShare 1.4 Addendum



AutoShare, a freeware EIMS companion application.
A list server and auto-responder for the Macintosh.
This document is copyright © 1996-1997 Mikael Hansen.


The AutoShare 1.4 Addendum explains the bug fixes and the new features added to AutoShare since the AutoShare 1.0 Documentation was written (entries marked with an asterisk (*) are new in version 1.4).

Be sure to read the AutoShare Home Page (www.dnai.com/~meh/autoshare/ on the Internet). An overview of the AutoShare documents is available as well.


Table of contents


Using AutoShare for the first time

AutoShare, a freeware EIMS (AIMS, MailShare) companion application, is a list server and auto-responder for the Macintosh. To get going right away, please browse the above documentation and read the Easy Does It document in the Samples folder carefully.

EIMS (Eudora Internet Mail Server), a freeware SMTP and POP3 mail server for the Macintosh, may be downloaded from http://www.eudora.com/freeware/.


Upgrading AutoShare

A number of changes makes the new version different in some ways, so please study this document thoroughly and make sure to clear your current log and the current work files in your Archives folder when installing this version of AutoShare.

When AutoShare starts up for the first time (when upgrading from versions prior to 1.1), it automatically updates to the new resource format of the AutoShare Preferences file in the AutoShare folder within the System 7 Preferences folder. It will then empty the data fork in the AutoShare Preferences file and delete the AutoShare Times and AutoShare Hosts files.

When upgrading from 1.2 to 1.3, be aware that remote passwords have been made list-specific. This means that the passwords are no longer stored in STR# 201,22 (now used for the contents of the X-List-Host RFC field), but rather in STR# 1000...,22. If you have created any passwords, you must move these at the time of upgrading from 1.2 to 1.3, using the Admin, AppleScript or a resource editor.

Version 1.3 also simplifies the various AppleScript Options parameters by naming all of them simply Options. The underlying codes have not changed, so all of your scripts will get updated automagically. 1.3 furthermore adds new properties to the Misc Options and List Options classes and introduces the Send Mail command.

When upgrading from 1.3 to 1.4, be aware that new file extensions (.text and .txt) have been assigned to digests and text archives.

Version 1.4 also updates the AppleScript dictionary in a number of ways. The Quote property in List Options has been changed from a boolean value to a number (indicating a percentage). New List Options properties are RFC Headers, List Stuff, Address Protection, Tip Of The Day, Approval Both and Hard Unsubscribe. All boolean types in List Options have changed to non-boolean types to accommodate the default/override values. New Misc Options properties are Line Format, Keep Up, Processing, Status Window Position, Hide Window (formerly a command!) and Misc Stuff.

Version 1.4 furthermore includes a number of significant speed and memory enhancements.


New features

List-specific features and scripting in AppleScript, these two more sizeable in description than the rest of the features, have much in common as the latter is used to configure the former. Then follow the AutoShare Admin and the information for the remaining features and changes.

The AutoShare Preferences file and its list-specific configuration

You may skip the section on The AutoShare Preferences file and its list-specific configuration, if you prefer to do so. All preferences, only in part supported by the user interface of AutoShare, are fully scriptable as described in the following section on Support for scripting. You may also wish to go straight to The AutoShare Admin, whose user interface benefits from the full scriptability of AutoShare and so has access to all preferences.

The terms default and override are used often in this section. The generic meaning of these two words is applied to the list-specific configuration of AutoShare to indicate, that if you don't go out of your way to configure a given setting for a list, the respective general setting will be used instead. Many lists frequently share the same settings, which conveniently may be configured on the general level (a list-specific setting defaults to a general setting), whereas truly list-specific settings may be configured on a list level (a list-specific setting overrides a general setting). As a rule, strings being blank and numeric values of -1 are most often the override values indicating default.

The AutoShare Preferences file resides in the AutoShare folder within the System 7 Preferences folder and is created automatically by AutoShare, when starting up.

AutoShare also initializes the list-specific settings in this file by creating standard default values, when starting up. The list-specific configuration is stored in STR# 1001 and upwards, one STR# per list. Index numbers for fields and description of values within these are:

STR# 1000 holds the general configuration for lists and uses the layout of fields and values for the list-specific settings. You probably have to update the configuration for only some of the fields for a given list: if the fields marked in the general configuration contain the same data as you would like to apply to the list, they are considered default values for the list if you leave the respective list-specific fields alone. Some server configuration not relating to lists is kept in STR# 201 (string values default to blank): The user interface of AutoShare takes care of STR# 1000,2, STR# 201,3 plus all configuration in STR# 202, 203,1-6 and 204 (206 has no interface at this time). The rest cannot be configured within the AutoShare interface. You may use a resource editor (such as ResEdit), or much better, an OSA-compliant scripting language such as AppleScript (specific commands are supported in most cases, the SetRes command is needed in a few instances only) to update your configuration for the above. The configuration data may be viewed in the AutoShare Analysis file. Or perhaps best is the user interface of the AutoShare Admin, which communicates with AutoShare via scripting.

Support for scripting

You may skip this section on Support for scripting and go straight to the section on The AutoShare Admin.

Apple Events scripting using AppleScript is perhaps the most important addition to System 7. This was enhanced in System 7.5 by introducing the scriptable Finder. AutoShare is fully scriptable, allowing you a convenient way of remote configuration. If you haven't tried using AppleScript, please locate the part of your System software that includes the files such as the Script Editor.

The various commands and properties in AutoShare's Apple Event dictionary may be viewed by dragging the AutoShare icon onto the Script Editor icon.

Once you have completed the installation of the AE system software, you may want to look into features like Program Linking, which enables you to control scriptable software from another Mac on the same AppleTalk network, even if you have access to the network via AppleTalk Remote Access (ARA). Program Linking is configured this way.

A number of AppleScript commands, SetRes, GetRes, Analysis, Subscribe, Unsubscribe, GetSubscriber, GetSubscribers, SetList, GetList, GetLists, SetMisc, GetMisc, SetFolders, GetFolders, SetTimes, GetTimes, SetHosts, GetHosts, SetFilters, GetFilters, Review, Write Log, GetStat, File Mail and Send Mail, have been added to AutoShare's support for scripting. The required commands, Run and Quit, are of course still supported. Furthermore, a single AppleScript script can perform several changes.

On the topic of errors, it is important to distinguish between actual AppleScript errors (most often unlikely) and a given AutoShare request not being successful (likely to happen from to time). When issuing for instance the GetSubscriber command, no result will be returned, if an AppleScript error, e.g. when fetching a property, occurs. On the other hand, an empty result will be returned, if there are no AppleScript errors, but, say, the subscriber could not be found. Your AppleScript scripting should take these kinds of situations into consideration.

The two AppleScript commands, SetRes and GetRes, set and get STR# resources in the AutoShare Preferences file. The feature is aimed at users who prefer not to use ResEdit.

The AppleScript syntax for SetRes is:
SetRes resID <resID> resIndex <resIndex> newString <newString>
returns <newString>
The AppleScript syntax for GetRes is:
GetRes resID <resID> resIndex <resIndex>
returns <oldString>
A STR# resource for test purposes is located at 1999,1 (the resID is 1999, and the resIndex is 1). It is highly recommended that you issue a GetRes command and look at the result before issuing a SetRes command. Here is a combined sample:
tell application "AutoShare"
set myString to (GetRes resID 1999 resIndex 1)
display dialog "[" & myString & "]"
SetRes resID 1999 resIndex 1 newString "I love to script"
end tell
Some AutoShare features call for such direct configuration. It relates to a few undocumented features, but also to a number of documented features listed in the section about the AutoShare Preferences file.

Another three AppleScript commands, Analysis (generate an Analysis file), Subscribe (subscribe a user) and Unsubscribe (unsubscribe a user), have been added, as they may come in handy for remote configuration using Program Linking.

The Unsubscribe command supports the list being all, so all lists are processed.

The AppleScript syntax for Analysis is:
Analysis [Email <Email>]
returns nothing
If no Email parameter is used, then the Analysis file is mailed to the main listmaster, otherwise it is mailed to the specified address.
The AppleScript syntax for Subscribe is:
Subscribe List <List> Email <Email> [Name <Name>]
returns <status>
If the optional Name parameter is not used, the name defaults to the e-mail address.
All or some of four properties may be added, using the optional parameter Options:
Subscribe List <List> Email <Email> [Name <Name>] [Options {Subscriber Conceal:<True or False>, Subscriber Digest:<True or False>, Subscriber Mail:<True or False>, Subscriber Ack:<True or False>}]
returns <status>
The AppleScript syntax for Unsubscribe is:
Unsubscribe List <List> Email <Email>
returns <status>

The AppleScript syntax for GetSubscriber is:
GetSubscriber List <List> Email <Email>
returns <set of options>

The AppleScript syntax for GetSubscribers is:
GetSubscribers List <List> [fromIndex <fromIndex> counterIndex <counterIndext>]
returns <list of a list's subscriber addresses>

The AppleScript command, SetList (list-specific settings), has been added, as it is a documented feature currently not found within the interface. When the List property is not used, the remaining properties are directed towards the general settings in STR# 1000.

The AppleScript syntax for SetList is:
SetList Options {<various properties>}
returns <status>
The GetList command returns the information about a given list. The only useful property to be used is the List property; if you would like the general list settings to be returned, then simply omit the Options parameter.
The AppleScript syntax for GetList is:
GetList [Options {<various properties>}]
returns <set of options>
The GetLists command returns a list of lists.
The AppleScript syntax for GetLists is:
GetLists
returns <list of lists>
The AppleScript commands, SetMisc, SetFolders, SetTimes and SetHosts, are directed towards the configuration also being accessible via the user interface. The AppleScript syntax is much like that of SetList:
The AppleScript syntax for SetMisc is:
SetMisc Options {<various properties>}
The AppleScript syntax for GetMisc is:
GetMisc
returns <set of options>
The AppleScript syntax for SetFolders is:
SetFolders Options {<various properties>}
The AppleScript syntax for GetFolders is:
GetFolders
returns <set of options>
The AppleScript syntax for SetTimes is:
SetTimes Options {<various properties>}
The AppleScript syntax for GetTimes (use File) is:
GetTimes [Options {<various properties>}]
returns <set of options>
The AppleScript syntax for SetHosts is:
SetHosts Options {<various properties>}
The AppleScript syntax for GetHosts is:
GetHosts
returns <set of options>
The AppleScript syntax for SetFilters is:
SetFilters Auto <File> Options {<various properties>}
The AppleScript syntax for GetFilters is:
GetFilters Auto <File> [Lists <Type>]
returns <list of filters>
The AppleScript command, Review, has been added, so that a subscription list may be mailed to the main listmaster or a specificed e-mail address. Write Log enables you to send and insert a string into the log. GetStat returns various status information. File Mail lets you create a message file in the Filed Mail folder, as if a sender sent a command to the list server, and Send Mail is a scriptable way of sending your own mail .

The Review command supports the list being all, so all lists are processed.

The AppleScript syntax for Review is:
Review List <List> [Email <Email>]
returns <status>

The AppleScript syntax for Write Log is:
Write Log logString <logString>
returns nothing

The AppleScript syntax for GetStat is:
GetStat
returns <various status information>

The AppleScript syntax for File Mail is:
File Mail Name <Name> Email <Email> Command <Command>
returns <status>
The AppleScript syntax for Send Mail is:
Send Mail To {Email: <Email>, Ename <Name>} From {Email: <Email>, Ename <Name>} [Subject <Subject>Body String <Body String>Body File <Body File>Precedence <Precedence>Body Header <Body Header>Body Footer <Body Footer>]
returns <status>
The AutoShare Sample Script in the Scripts folder includes all of the above commands. The folder also includes scripts for each individual AppleScript command, and a CGI subfolder contains scripts for an AppleScript CGI for AutoShare. You may also want to read The AutoShare AppleScript Tutorial.

The AutoShare Admin

The AutoShare Admin is a configuration tool for AutoShare and offers a welcome user interface. Written using FaceSpan version 2.1, the AutoShare Admin takes full advantage of the scripting dictionary of AutoShare. The Admin is fat, thereby being native to both 68K and PowerPC.

The Admin comes as a Miniature application, which means that the FaceSpan Extension must reside in the System 7 Extensions folder for the Admin to work.

The AutoShare Admin may be used on any Mac on the same AppleTalk network that the Mac running AutoShare is located on. Please read the above notes on configuration of Program Linking. When using the Admin remotely, be sure to put a copy of the AutoShare application on the Mac (preferably in the same folder as the Admin) on which you are using the Admin, so that the AutoShare AppleScript dictionary can be read by the Admin. Or you may use the ResEdit file entitled AutoShare (located in the Admin folder), which contains the AutoShare AppleScript dictionary only.

Balloon help has been added to the List, Lists and Subscriber windows, so that you may read about the various fields of these windows in detail.

PowerPC native

AutoShare, written using Metrowerks CodeWarrior Pro (CW 12), is both 68K (in the 68K folder) and PowerPC (in the PPC folder) native.

The development environment of AutoShare does not rely on a framework such as PowerPlant or MacApp. The PowerPC native version is compiled and linked directly from sources to application and does not use a PowerPC conversion tool such as MacApp2PPC.

When AutoShare 1.0 was released, it was the first 68K list server for the Mac, and with the release of version 1.1, AutoShare was also the first true PPC native list server for the Mac.

Not mandatory on startup disk

AutoShare is no longer mandatory on the startup disk anymore; this also implies that EIMS (AIMS, MailShare) and AutoShare may reside on two different Macs on the same AppleTalk network.

Folders and aliases

In the Folders dialog box, aliases are already resolved immediately when using the Select buttons. Now path aliases are also resolved when pressing the OK button, including paths being typed in manually.

The AutoShare folder in the System Preferences folder may now figure as a folder alias. The alias to the actual folder located elsewhere is resolved when AutoShare starts up.

Incoming and outgoing files

When starting up, AutoShare now creates a folder entitled AutoShare Temp on its Mac in the System Preferences folder; aliases are not supported for this new folder. All processed files will now enter this new folder first before a fast move takes them to the Incoming Mail folder. With this folder residing on another Mac, this insures no lost file forks and minimizes the traffic on the network.

When processing incoming files in the Filed Mail folder, AutoShare no longer waits for 5 seconds before processing the file (see STR# 2000,8 in the application's resource fork). It has been changed to zero seconds, and AutoShare now relies completely on whether the data and resource forks of the file to be processed are closed.

List-specific logs

Logs are mailed to both the primary administrator (the overall listmaster gets the complete log) and the secondary administrators (the list-specific listmasters get respective list logs for lists, whose list-specific administrator address is specified).

The primary transaction information listed as single lines (formatted as a series of transaction information tokens using space delimiters) in the logs applies to the following transaction types (the tokens are listed after the colon):

Moderated, announcement and private lists

When a contribution is sent to a moderated list, it gets redirected to the listmaster, who may choose to post it or not; if the moderator uses Eudora, the Redirect (or Redirect To) is recommended when posting other people's contributions. When a contribution is sent to an announcement list, the contribution is returned to the sender. In both cases, only the listmaster is able to post to the list. The listmaster address is fetched from the administrator address (from the Preferences menu, choose Miscellaneous).

The standard list types are Subscription (contributions require subscription), Open (contributions do not require subscription), Moderated (the listmaster views contributions before being posted), Announcement (only the listmaster may post contributions) and Private (subscriptions are not allowed).

It may be added that the list-specific configuration enables list-based defaults for the subscription Options. If you prefer subscribers to for instance receive copies of their own contributions without any separate update of the subscriber's options, this is the way to go.

Posting privilegies may be turned on or off for individual subscribers (subscription, open and private lists). The post and nopost tokens may be applied as any other SET option, but with one important restriction: the subscriber cannot successfully use the two new tokens as a valid option within a SET command. They are administrative tokens only (whose option code is '4') to be used by the administrator (scripting commands, remote administration by e-mail or direct editing of main list files).

Tip Of The Day lists (*)

Any list may be additionally configured to be come a Tip Of The Day list in AppleScript by the Tip Of The Day property in List Options (STR# 1000..,27); the Admin, see the More List window. When configured as such, list contributions will not be posted immediately, but rather one at a time at given intervals. Tip Of The Day list contributions are currently being posted when digests are sent.

Subscriber addresses

An Internet mail message (see RFC 822) contains two parts: 1. the visible contents, which includes a header of RFC fields as well as an optional body and 2. the (usually) hidden envelope, which includes delivery information. Two of the RFC field headers may be From and To, which often (but certainly not always) are identical to the envelope's sender and recipient respectively. EIMS stores the contents and the envelope in the message file's data fork and resource fork respectively.

AutoShare has historically used the envelope sender, not the RFC From field, to determine the address of a list subscriber, as the envelope sender is generally considered to be the real address, although not visible when viewing the mail message. More often than not, the two are identical though.

If you would like new subscriber addresses to be extracted from the RFC From field, you may use the RFC From property in the AppleScript Options (Misc) to enable this. This means that the list files will contain the RFC From addresses for new subscribers, which will be used whenever a list server request or a list contribution takes a place. The envelope recipient of a list server request to be returned will furthermore be updated to the address in the RFC To field.

Subscriber address protection (*)

The address protection feature of AutoShare hides the e-mail addresses of subscribers and replaces them with special address tokens. When a given list has this feature enabled, it is applied to list contributions, the digests, the standard archives and the fully automated web archives.

Using address protection prevents the action of harvesting e-mail addresses for unintended purposes.

When a subscribe command takes place, the list-specific index file in the Protected Addresses folder inside the AutoShare folder of the System 7 savvy Preferences folder is updated (entry is added). Same for an unsubscribe command (entry is removed). When a review command is issued, the e-mail addresses are replaced by corresponding address tokens.

When a subscriber posts, nothing is initially different. But when the list server receives the list contribution, the RFC From field body is replaced with a special address token, and all RFC X-Sender fields are removed. It is important that the body of your list contribution does not display your e-mail address.

When the subscriber would like to e-mail another subscriber off the list, the mail, with '<list>space<address token>' placed in the subject, is sent to the 'protected@<domain>' e-mail account, which redirects the mail to the recipient.

The envelope recipient gets updated, and the mail message is moved to the Incoming mail folder. If there is no match for the envelope recipient in the index file, the mail is returned to sender.

When sending an initial mail this way, it is encouraged that you be brief and merely state the purpose of your initiative, so that the communication may switch to the direct use of actual e-mail addresses on both sides. It is not intended that the server be allowed access to the contents of your mails more than necessary.

The address protection feature is enabled in AppleScript by the Address Protection property in List Options (STR# 1000..,26); the Admin, see the More List window.

We now move onto the issue of what is entitled spam, a term generally used loosely for various abuse of e-mail. You may think of spam as junk mail of many flavors.

It is next to impossible for a computer to figure out if a given mail is abusive, as the contents isn't reviewed in a meaningful fashion. Several steps may be taken though: 1. applying address protection prevents the spammer from harvesting e-mail addresses, 2. spam mails are often lengthy, and limiting the number of lines for list contribution bodies often helps, 3. writing a Before Processing process extender, which parses the mail for various words and optionally deletes the message file before it gets processed, and 4. using mail-back confirmation requires an additional effort from the spammer, who often prefers to move onto another easier target.

Subscriber aliases

The list index files in the Subscriber Aliases folder inside the AutoShare Preferences folder automatically create a correlation between the envelope sender and RFC From addresses whenever new subscribe requests (standard message files only) take place.

The format per entry is alias address, so if the subscriber addresses are envelope sender based, the RFC From address becomes the alias, and if the subscriber addresses are RFC From based, the envelope sender address becomes the alias.

When an unsubscribe request (standard message files only) takes place and the address isn't found in the main list file, the address will then serve as an alias and be looked up in the index file, and if the corresponding address is present in the list file, this address will be unsubscribed.

To make this feature active, you may use the Subscriber Aliases property in the AppleScript Options (Misc).

New list server command features

Search is a new list server command which lets you search for strings in archive files. The syntax is search <list> <string>. To use it, you must include a /=search line in a search doc file.

All may be used for the Unsub, Query, Set, Index, Get, Review and Search commands to apply the command to all subscribed lists, e.g. query all.

The subscriber name has been made optional in both the list server Sub(scribe) command and the AppleScript Subscribe command.

Suppressing messages

One of the good things about AutoShare is that it applies the Precedence: bulk by suppressing responses and list contributions for mails including it. And outgoing list contributions get it inserted automatically. This means less of a risk of vacation notices being posted to lists.

Auto-replies and vacation notices also insert Precedence: bulk. Furthermore, incoming messages with Precedence: junk and Precedence: list also get suppressed.

Filters directed at complete or partial addresses, e.g. list servers or individuals, may be used on top of this so safeguard against messages without a Precedence: RFC field header. In the Filters folder, the files are named based on the list name just like in the Listserv folder.

Text and/or HTML archives (*)

Text archive files now no longer use the .html and .toc extensions. The new unique file extensions are .text for the main file and .txt for the table of contents file. As these extensions reflect text formatted contents and not HTML formatted contents, the digests now also use this new set of extensions.

It is strongly recommended that you update all current files in your Archives folder to reflect the new convention!

You may choose both text and HTML formatted archives (rather than just one or then other). Having chosen this option (in the AutoShare application or using AppleScript; the Admin, see the List window), both text and HTML formatted archive files are created if necessary and updated when a list contribution is processed. The Index command will list both .text and .html file names. The Get command will format according to the file extension. The Search command will search both .text and .html files.

Rollover of archive files

The automatic archive file rollover is based on the number of list contributions. A maximum value may be configured. Default is set to 0, which means no rollover. For now, this value may be changed using the SetRes AppleScript command or in ResEdit. The Current.html and Current.toc files get renamed <date>.html and <date>.toc; likewise with the corresponding .text and .txt files.

When a rollover archive file is created, a note is added to the log file, so that the listmaster becomes aware of it. In the case of HTML formatting selected, the listmaster may then choose to issue a GET command to receive the fully formatted HTML file by mail, save it to a text file and store it in a folder on a web server, thereby offering a convenient access to the archives. This may be further enhanced by using the new search and indexing tool Apple e.g., a public beta is at www.cybertech.apple.com/Appleeg.html.

Automated web archives

Automated web archives need only an entry point folder path to be configured. An entry point folder may be viewed as a subtree inside your web server folder and contains one subfolder per list. Each subfolder holds complete html files created on the fly based on the html and toc files from the standard archives. Both the entry point folder and its subfolders also get fully updated index.html files to piece everything together.

The entry point folder path is configured within the list-specific settings, in AppleScript using the Web Path property in the Options (List). You may apply the one that is used most often as a general setting, but given lists such as private lists may choose to override with another path using a setting specific to the list. By assigning an invalid path, no web folders or files are created.

If you prefer to use your own html file in the entry point folder, then simply give this file a name other than index.html and make references to this file. It is assumed that your file references the index.html files inside the list subfolders.

Whenever a contribution takes place and the standard archives are updated, so are the web archives plus both the entry point level index.html file and the list subfolder index.html file.

A few changes have been made: all archived files now use hyphens instead of spaces, and some cosmetic changes have been updated for the archive files. It is recommended that prior archives be updated to reflect the new changes.

Specific to individual lists only (the general setting is always the above complete tree), the entry point folder may be configured to be the list folder itself; the upper layer of the subtree (the top-level folder and the top-level index.html) is not created, and the list folder is moved up one level to match that of the entry point folder. In AppleScript, use the Web Archives property (Complete versus Minimal) in the Options (Misc) to configure this selection.

Both Mac-to-HTML and MIME-to-HTML character conversions are automatically applied to both the standard and the fully automated web archives.

Remote administration by e-mail

Whenever a file arrives in the Filed Mail folder with a first body line beginning with your admin password, remote administration sets in. The list-specific admin password is configured in AppleScript by using the SetList command (or using the AutoShare Admin), as the following example illustrates:

SetList Options {List: "fun-l", Remote Password: "rosebud"} When applying remote administration by e-mail, let the first body line (if the subject mode for list server requests, then the subject field instead) follow this word pattern:

<password> <command> <e-mail> <list> <rest>
for instance
rosebud subscribe a@b fun-l Mr. X
Commands supported so far are subscribe (the 5th word is just the rest of the line), unsubscribe (the name is not needed), set (the option is the 5th word), review (use a dummy e-mail address as the 3rd word) and analysis (the password and the command are adequate). The password is case-sensitive, the remaining parameters are not. All of these commands returns an e-mail to the sender with a status; the original command line is included, but the password is replaced by a generic word for safety reasons.

The post command is different from the above commands in several ways. You may use it to post to a list regardless of your client software's configuration, as the e-mail address and user name are picked up from the e-mail and rest tokens respectively. The list token is used to update the recipient, so the contribution gets posted to the list; no e-mail is returned to the sender or the contributor. The body of the contribution message is what follows the initial passworded line (if the subject mode, then put the passworded line in the subject and the subject as the first body line).

The password command may be used to change the password. Enter the new password as the 3rd word. If no list is specified, the request is aimed at the overall password. Both the old and the new passwords are replaced by generic words in the returned message. An e-mail is returned to the sender with a status.

The application and system commands have been added to accomplish remote launching and quitting of applications as well as system restart and shutdown. For either command, you may enter Launch or Quit as the 4th word, and the application command requires the 4 character creator (signature) code of the application in question in the 5th word. The 3rd word is ignored. PS: if you put application creator codes in STR# 206 of your AutoShare Preferences file, AutoShare will launch any of these applications (if not already running) every ten minutes. Keep them up!

Multiple lines using the above format are supported (in the body mode only). AutoShare stops processing the body once there are no more lines beginning with a valid password. While a post line must be the last of one or several passworded lines, it need not be the first.

For safety reasons, I highly recommend the recipient be autoshare@....

The passwords for remote administration by e-mail have been made list-specific in version 1.3, so you need to update all of your passwords to make your configuration current, using the Admin or AppleScript (if you edit your Preferences using a resource editor, please pay close attention).

If AutoShare detects a valid list in 4th word, the list-specific password works as well as the overall password, which works whether or not a valid list has been specified.

It may be added that the somewhat more complex Script By Mail AppleScript sample package offers the alternative of issuing AppleScript commands via e-mail.

Subscriber and administrator web forms

AutoShare offers web form support for both subscribers and administrators. The sample web form HTML files (designed by James Berriman and Bill Suarez) in the Samples folder illustrate how these forms are filled out and then e-mailed to the server once a button is pressed.

Upon arrival, AutoShare detects the Content-type: application/x-www-form-urlencoded RFC field in the message and subsequently turns the mirrored web-originated message files into standard message files (list server requests and remote administration by e-mail respectively). Complete URL decoding is applied to the data received from the web browser.

A subscriber form may use the command, list, name and option tokens as well as the subscribe, unsubscribe, set and review commands.

The remaining commands, new in version 1.4, are: list, index, get, which, release, query, search and help, and new tokens are file (for Get) and string (for Search). (*)

An administrator form may furthermore use the password and email tokens as well as the analysis command (the post, password, application and system commands are not supported in web forms).

Process extenders (*)

An AutoShare process extender, an external application, extends the processing of the AutoShare application itself. The term hook is used to designate the entry-point in AutoShare, where the external application, often a script application, is launched if necessary and its action is being processed.

When AutoShare comes across a hook, AutoShare sends an AppleEvent to the process extender is question, if available. A list of parameters, which the process extender may use, is included in the AppleEvent.

The parameters in the passed list of the AppleEvent are 1. the folder path of the message file, 2. the file name of the message file, 3. the envelope sender of the message file, 4. the envelope recipient of the message file, 5. the RFC From body field, 6. the RFC To body field, 7. the RFC Subject body field, 8. the RFC Date body field, 9. the list name and 10. the contribution alert type.

The contribution alerts are the messages inserted into the beginning of the body, when contributions are not immediately posted for various reasons: 1. not subscribed, 2. announcement list , 3. subscriber not allowed to post, 4. response is smaller than quote, 5. moderated list and 6. too many lines in contribution.

For suggested variable names for the above parameters and contribution alerts, see the Before Processing sample Template process extender.

Process extenders reside at the top level inside the 'Process Extenders' folder, which resides in the same folder as the AutoShare application. Aliases are supported for process extenders, so that these may physically reside elsewhere.

There are several sample process extenders inside each sample type folder. One from each folder may be made active by placing it at the top level inside the 'Process Extenders' folder. All sample files are script applications with the source preserved ("Save As..." Application with both "Stay Open" and "Never Show Startup Screen" enabled).

The following describes the various AutoShare process extenders and also makes references to the sample process extenders. The class and event IDs used are in parenthesises after the process extender name.

Before Processing ('AuBP', 'aUBP')

The Before Processing hook is placed at the very beginning of the processing of a message file in the Filed Mail folder. The execution of the Before Processing process extender is triggered by AutoShare becoming aware that a file resides in the Filed Mail folder.

Within the Before Processing sample folder, the Template process extender illustrates the basic starting-point. The main AppleScript handler merely picks up the call from AutoShare. The purpose of the idle handler is to reduce processing time being allocated to the application when the main handler is not being called.

The List Parameters process extender displays the various parameters being passed from AutoShare. Be sure to have AutoShare running in the background when testing this sample.

The Unconditional Filter process extender intercepts the main AutoShare processing by copying the message file to another folder and completes this task before AutoShare begins its actual processing of the file. If the process extender deletes or moves the file, AutoShare is left with no processing of its own to do.

The Write Log process extender writes a line to the AutoShare log. This sample is particularly interesting, as the sample application calls the very same AutoShare application, which triggered it. AutoShare waiting for the process extender to complete its task causes a Catch-22 situation, because AutoShare does not respond to high-level events during instances of its main processing phase to avoid various high-level event and open file conflicts. The trick is to let the process extender have its calls to AutoShare bypass its requests for high-level event replies; the actual task will be processed instantly though.

After Processing ('AuAP', 'aUAP')

The After Processing samples resemble those of Before Processing. The only difference is the time of being triggered and thereby the message file. This type of process extender is executed just before the final processed file is copied to the Incoming Mail folder.

Subscribe ('AuSU', 'aUSU')

The Subscribe Write Log sample writes a line to the AutoShare log. Be sure not to have your process extender delete, move or otherwise change the message file.

The FileMaker Pro sample creates a new record in a FileMaker Pro database file having a very simple data structure.

The Send Message sample sends a basic welcome message to the new subscriber.

Unsubscribe ('AuUS', 'aUUS')

The Unsubscribe Write Log sample writes a line to the AutoShare log. Be sure not to have your process extender delete, move or otherwise change the message file.

The FileMaker Pro sample looks up the subscriber in the database and sends a message of when the original subscription took place.

After Digest ('AuAD', 'aUAD')

The After Digest Write Log sample writes a list-specific line to the AutoShare log.

Contribution Alert ('AuCA', 'aUCA')

The Contribution Alert Multiple Alerts sample illustrates how to return a list of strings to AutoShare; note the AppleScript return command in particular. The row of lines will override the default text of the given alert message.

You distinguish among the various contribution alert types by using the code of the contribution alert type parameter. The sample shows this in full.

Test Bounce ('AuTB', 'aUTB')

The Test Bounce Write Log sample writes a line to the AutoShare log.

As the parameters reflect the Test Bounce file in the AutoShare Temp folder, you may choose to delete this file and instead send another message to the subscriber in question.

System ('AuSY', 'aUSY')

The System Write Log sample writes a line to the AutoShare log immediately before a System command using remote administration by e-mail takes effect. As the normal purpose of the contribution alert type parameter does not apply, the parameter is instead used to indicate whether the Mac is to be 1. restarted or 2. shut down.

Contribution related issues

A setting now holds the maximum of lines in the body of a message contribution, as defined by the listmaster. Default is no maximum applied. When the number of lines has been exceeded, the message gets forwarded to the listmaster, who determines whether to forward it to the list or not.

To reinforce that the unquoted part of a response contribution must be at least a given percentage of the complete message body, change the proper list-specific setting to this percentage. If it does exceed more than the percentage, the message is returned to sender. John Norstad's NewsWatcher applies this restriction to news responses (50% only though), if the news server in question is configured to reject postings which contain more quoted text than new text.

The .m and .d work list files

EIMS supports the SMTP EXPN command, which is an optional part of RFC 821. This allows anyone to telnet to your server on port 25 and 'expand' an EIMS mailing list to the full list of addresses. If you don't want the names of your subscribers accessible to the public, you can enter an alternate name for the EIMS .m and .d accounts in the Work Lists field of AutoShare Admin's List window. Someone could still telnet to your server, but unless they can guess the account name you supply, they won't be able to EXPN your list. For example, you could enter xyzzy in the work lists field. In EIMS, name your accounts xyzzy.m and xyzzy.d. In the field at the bottom of the EIMS account setup window, where you give the path to the mail list file, use the same path you normally would. In other words, if your list is called Fun-L, you'd continue to use Fun-L.m and Fun-L.d as the names of the actual lists, since using the Work Lists field has no effect on those names. Work Lists merely gives an alternate name for the EIMS accounts that point to the mail list files.

'X-' RFC fields

The X- RFC fields in list contributions serve as helpful information.

The X-List RFC field headers and respective field bodies are:

X-List-Software, X-List-Admin and X-List-Help were formerly known as X-Listserver, X-Administrivia-To and X-See-Also respectively.

X-List-Digest, X-List-Archive, X-List-Post and X-List-Host are new.

Other X- headers and respective fields are

MIME RFC fields

AutoShare may be configured to use MIME Quoted-Printable encoding.

When the MIME property in the AppleScript Options (Misc) is set to Text Plain (default), the following MIME RFC field is inserted after the Mime-Version field:

     Content-Type: text/plain
And when the property is set to MIME QP or QP Always, the following MIME RFC fields are inserted after the Mime-Version header field:
     Content-Type: text/plain; charset="iso-8859-1"
     Content-Transfer-Encoding: quoted-printable
Mac-to-MIME conversion is applied accordingly in the body of the outgoing message.

MIME QP: The MIME property makes a difference for the outgoing message files that are originated by AutoShare and not directly derived from message files arriving in the Filed Mail folder (such as logs, digests and admin notifications). For list contributions and auto-responses, Mac-to-MIME conversion will depend on the MIME RFC fields of the original message as well; the Mac-to-MIME conversion does not take place unless the 'Content-Transfer-Encoding: quoted-printable' field is located (besides the MIME property being set to Quoted-Printable).

QP Always: The MIME Quoted-Printable encoding takes place whether the message file is originated by AutoShare or not.

AutoShare offers MIME Quoted-Printable support for auto-responses with enclosures as well. (The name of the enclosure file will be added to STR# 8193,1 (2 and 3 are also used) of the outgoing message to insure that boundary lines are inserted correctly at the time of the Mac-to-MIME conversion.)

Monthly help files

Monthly help files are mailed to list subscribers at the beginning of every month on a per-list basis when line-based "Month.<list>" files are added to the docs/autoshare folder. An example is "Month.fun-l".

Both message and digest subscribers receive the monthly help files.

If several lists are to share one monthly help document, you may create aliases reflecting the normal file name format and pointing to the same document.

Subject prefixes

The Subject Prefix property has been added to the Options (List) in AppleScript, so that a list-specific prefix may be inserted in the subject line of list contributions. The prefix will appear in front of the subject itself, or if the subject starts with Re:, then immediately after this, so that e-mail clients may still sort messages correctly.

If a + (plus sign) is appended to the prefix, the prefix will appear at the end of the subject instead.

Headers and footers

Headers and footers appear in list contributions when line-based "Header.<list>" and "Footer.<list>" files are added to the docs/autoshare folder. An example is "Footer.fun-l".

Headers and footers also appear at the beginning of and end of digests.

For a moderated list, the list contributions forwarded to the list master do not include headers or footers. They will be inserted when the list master posts the contribution to the list.

If several lists are to share one header or footer document, you may create aliases reflecting the normal file name format and pointing to the same document.

Rotating banners (*)

Rotating banners can be applied by simply putting your banner text files in a folder and replace your regular header and/or footer file with a Finder alias to the folder. AutoShare will then randomly select the banner(s) each time a list contribution or a digest are processed.

Auto-response tokens

Two new commands are supported for the standard auto-response documents: You may place both of these anywhere in the files, as long as they reside on lines by themselves

Searching and sorting subscription lists

The subscription lists have always been updated by AutoShare to reflect a ordered list by domain, because some mail servers are able to speed up the throughput of outgoing mail this way, and because it may come in handy when manually browsing list files.

The change is that AutoShare now offers binary searches of the line-based subscription lists, so that a search for a given address is completed much faster than before. This is in part accomplished by verifying at start-up that the lists are sorted, and when not, sort them using a QuickSort algorithm.

The searching, sorting and insertions for lists are configured using the List Sort property in the Options (Misc); the new status will be saved to the disk settings immediately, but will not become active until the Run command has been issued or AutoShare is restarted. The property may be set to Domain, User or Unsorted; when configured as the latter, AutoShare will not check for lists being ordered when starting up and will apply a simple linear search when looking up subscribers; new subscribers will in this case be appended to the end of the list file.

When sorting, the AutoShare application heap memory is utilized as tightly as possible. Each subscriber takes up 4 bytes plus the number of characters in the address line in question. With an average subscriber string length of 36 characters, a list file of 1,000 subscribers requires around 40K at the time of sorting. It may be noted that if you stick with the same configuration from day one, no sorting will ever have to be applied as new subscribers are placed in their proper location from the very beginning, always leaving the list file sorted.

When subscriber records are added (sub), replaced (set) or deleted (unsub) for a ordered list, an efficient file processing technique optimizes the speed dramatically. Even huge list files will require little time to stay fully updated at all times.

Setting up a poll

An account name with the user name of Poll has been turned into a very special auto-response account. No extra configuration is required, it's just like setting up a regular auto-response account.

Anyone may vote on a given topic by sending a mail to the Poll address. The topic of the vote is based on the specific subject line. The actual vote of the sender is based on the first line of the body. Whenever a sender tries to vote, the overall vote statistics are returned. If it's the sender's first try, the pool of votes gets updated, and following attempts results in informing the sender of the number of attempts so far.

The poll account may be used to gather all kinds of distribution data based on the key strings (max 20 characters each) in the body. The poll account rejects all subjects which have no corresponding document or uses the Default document. The poll action is triggered by the /=poll token, which should be placed in all docs, also the Default doc, in the poll folder. The poll status returned to the sender shows the overall distribution sorted by selection, and graph bars help illustrate the results.

A set of pre-defined key strings may be attached to a poll. When an invalid key string is encountered, AutoShare returns a note to the sender asking for another try. The series of case-insensitive key strings resides in the 'STR ' resource, beginning at 1001 and upwards, of the poll file in question (no user interface has yet been designed).

Mail-back confirmations

The mail-back confirmation is a new feature requiring the user to respond to a handshake confirmation before the mail message is processed. Since the user must reply to a return message with a keyword which is included in the reply, the server knows for sure that the mail message in fact is from that one user.

Two new folders are introduced, the Mail Back folder and the Hold Mail folder. The mail-back feature works on a per account basis, so if you would like mail-back enabled for a given account, you re-configure the EIMS Save as files account to point to not the Filed Mail folder, but the Mail Back folder instead. Once the message file appears in the Mail Back folder, AutoShare moves it to the Hold Mail folder and puts a new message file in the Incoming Mail folder, asking the user to confirm by replying to the mail; the first line in the body displays the confirmation key, which is the unique name of the original file generated by EIMS. When the confirmation message file arrives in the Mail Back folder, AutoShare checks the first line in the body, and if it matches the name of a file in the Hold Mail folder, this file is moved into the Filed Mail folder, and the confirmation file is deleted.

The contents of the returned mail-back message to the user will go beyond including just the confirmation key in the first line of the body, if you put a line-based text file entitled Mailback in the autoshare/docs folder. A blank line and the contents of this file will be added, thereby explaining the user what to do. The /=original and /=subject tokens are supported in the Mailback file.

Deletion of unconfirmed message files takes place automatically. The Hold Mail Check property in the Options (Misc) (STR# 201,12 in the Prefs) indicates in minutes (default is 10 minutes) how often AutoShare should check for expired files, and the Hold Mail Expire property (STR# 201,13) indicates in minutes (default is 600 minutes = 10 hours) the duration before expiration takes place from the time the file was created by EIMS.

The AutoShare account is a unique and more complex case, as you may want some commands enabled for mail-back and others disabled. To feature this, a new list-specific Mailback property is introduced in the AppleScript Options (List) and corresponds to STR# 1001...,20 in the Preferences file. If the string is blank, STR# 1000,20 is looked at for the general setting, and if the string there is blank too, no mail-back is enabled for the given list. You may add N (None) to the list-specific string to avoid use of the general setting.

The A (All) enables mail-back for all commands for a given list, and if a command does not contain a reference to a list, the general setting is used. Here are the letters for the various commands: S=sub, U=unsub, E=set, Q=query, R=review, I=index, G=get, H=search, W=which, L=list, C=release.

The list-specific string SUQL indicates that the sub, unsub and query commands are mail-back enabled, while others are not; the status of the list command is determined by the general setting, as it is not specific to any given list.

If all STR# 1000...,20 strings are blank (default), no mail-back takes place for the list server account. It therefore doesn't matter whether the EIMS account points to the Mail Back folder or the Filed Mail folder.

Bounces and unsubscriptions

Configure your bounce account in EIMS as Save as files. Until you feel comfortable with the following bounce feature, it is recommended that the Keep copy box be checked, assuring you that things happen as before (the mail goes to the EIMS bounce mail account). The Save as files part should be configured in EIMS to point to a new folder, also configured in AutoShare using the Bounce property in the AppleScript Options (Folder) (use an empty path to not use this feature).

When using the automated bounce feature, it is strongly recommended that the bounce account not be identical to the EIMS postmaster account, as mail received by the bounce account is for AutoShare only. And as usual, it is a must that the domain of the bounce address reflect that of the mail server.

Whenever bounce mail arrives, AutoShare's bounce module will process the message file and subsequently send the admin a mail if a list subscriber could not be located. Otherwise the list subscriber is updated in the Bounces On Hold file located in the AutoShare folder inside the System 7 savvy Preferences folder. The subscriber address, the list name, a sent counter (initialized to zero), a received counter (initialized to zero) and an entry created time are the five pieces of information, which are added to each entry in the Bounces On Hold file.

Every so often (using the Bounce Send Mail property in the Options (Misc)), AutoShare sends a mail to each entry in the Bounces On Hold file, and the sent counter is incremented by one. If the subscriber address continues to bounce, the new bounce message causes the received counter of the entry to be incremented by one (additional bounces will not cause the value of the received counter to grow beyond the value of the sent counter, as it should not be a factor how busy the given list is), and once the received counter hits a given threshold (using the Bounce Received Threshold property in the Options (Misc)), the subscriber get unsubscribed, and the entry is removed from the Bounces On Hold file.

If the subscriber address does not continue to bounce, the sent counter continues to grow while the received counter does not, and once the difference of the two values is beyond a given threshold (using the Bounce Sent Threshold property in the Options (Misc)), the entry is considered stable and removed from the Bounces On Hold file.

Entries are also deleted when the current time exceeds the entry created time by a given threshold value (using the Bounce Delete Threshold property in the Options (Misc)). The purging takes place every time test bounces are sent.

The Bounces On Hold file includes entries based on soft bounces only. Hard bounces get unsubscribed immediately per the default behaviour (which includes sending a mail to the listmaster), but be configured to act as soft bounces. A hard bounce is defined as a sender situation which is not likely to change (such as the sender's address not known), while a soft bounce relates to a temporary situation (e.g. the mail server of the sender may be down due to a network problem). AutoShare does not support many bounce formats at this time, and the 550 code (user unknown) is the only one so far to trigger a hard bounce status.

Out of memory and low on disk space

When AutoShare is close to running out of memory or the server Mac is almost out of disk space, two types of reminders take place. Firstly, the incident will appear in the log file, and secondly, the administrator will receive an e-mail indicating that prompt attention is needed. Beware though that the reminders may not happen when starting up AutoShare, as the preferences must be fetched before logging or e-mailing can take place; AutoShare may shut down gracefully or enter the non-processing mode, if unsafe to proceed.

Situations relating to AutoShare being low on memory are often temporary, so one reminder only per incident will be issued. Future transactions will be processed in a normal fashion, although some specific transactions may cause history to repeat itself, at which times further reminders will be issued.

When a disk is close to being full, the situation is not likely to change much by itself. Both periodical and pre-processing checks applied to all involved volumes will be performed based on a worst-case scenario, and when the threshold has been hit, the processing of the current task will be completed if possible, the reminders will be issued, and AutoShare enters the non-processing mode. Once the situation has been resolved, AutoShare resumes normal processing.

When AutoShare gets low on disk space, it no longer shut downs, but instead moves into the non-processing mode, allowing only events (including AppleEvents) and Keep Applications Up to be processed. Messages are mailed to the listmaster every hour to inform of the low disk space situation. When adequate disk space has been restored (checking for this every so many minutes (defaults to 60); STR# 201,27; AppleScript, see the Processing property in Misc Options; the Admin, see the More Misc window), AutoShare returns to normal processing. (*)

Drag and drop onto AutoShare

I am not sure if this feature has any practical use, but you can drag and drop one or several line based text files onto the AutoShare icon. The contents of each file wil be appear in the body of a message mailed to the main list administrator.

Improvements and bug fixes

Version 1.4 (*)

Version 1.3

Version 1.2

Version 1.1

Version 1.0.1


Miscellaneous


Undocumented features


The small print

AutoShare, a freeware EIMS (AIMS, MailShare) companion application
A list server and auto-responder for the Macintosh
AutoShare is a personal project of Mikael Hansen in his free time and in no way relates to his work as such. Mikael Hansen accepts no responsibility for the use of AutoShare.
Last updated on September 8 1997 by Mikael Hansen